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An electronic commerce system and 
method has a number of computer systems 
connected by a network, including a broker 
computer system having a database of scrips 
representing a form of currency, a vendor 
computer system having a database contain- 
ing products which may be exchanged for 
the scrips, and a consumer computer system 
with which a user may initiate transactions 
to obtain the products contained in the data- 
base of the vendor computer system in re- 
turn for scrip. A wallet holds the scrip on 
the consumer computer system and is pro- 
tected with a user-supplied pass phrase. To 
strengthen the pass phrase, the wallet adds 
a nonce and a random string to form an in- 
ternal pass phrase. The length of the ran- 
dom string is determined by the processing 
power of the consumer computer system. 
Then, the internal pass phrase is hashed with 
another nonce to form a checksum, which is 
stored in the wallet along with the nonces. 
In addition, a portion of each scrip is en- 
crypted by hashing a unique nonce and the 
internal pass phrase, XORing the scrip with 
the hash, and storing the encrypted portion 
and the nonce in the wallet. To use the 




scrip in the wallet, the user provides the pass 
phrase. The wallet tests a hash of the nonce 

and pass phrase with different random strings against the checksum to determine whether the user-provided pass phrase is correct If so, 
then the wallet decrypts the scrip by XORing the recreated hash with the encrypted scrip. 
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ENCRYPTING SECRETS IN A FILE FOR AN ELECTRONIC MICRO- 
COMMERCE SYSTEM 
Background 

Field of the Invention 
5 This invention relates generally to electronic commerce systems and more particularly 

to using encryption to protect data in the system. 

Background of the Invention 

With the advent of electronic forms of communication, including telegraph, 

10 telephone, radio, television, and more recently digital networks, it has become possible to 
conduct commerce electronically using digital computer systems. Electronically encoded 
funds are different than physical currency in that it is a trivial matter to duplicate electronic 
representations of funds. The most difficult task faced in conducting computerized 
commerce is to detect the illegal re-use of electronic funds, e.g., double spending. 

15 Known electronic fund transfer systems generally require a "trusted" third party 

between the vendor and consumer to authenticate the validity of the electronic funds. The 
requirement of a third party adds expense to every transaction because of the cost of extra 
communications and encryption. In addition, current electronic fund transfer networks, e.g., 
Western Union and Federal Reserve banks, typically require physically secure 

20 communications media which is immune to "eavesdropping." Such secure networks are 
generally not available to consumers at large. 

Alternative methods of electronic fund transactions involve establishing a long-term 
relationship between the vendor and consumer, either through a subscription service or by 

1 
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billing accounts as are provided by credit card organizations. These methods are efficient at 
handling transaction requests, assuming a reasonable authentication scheme. However, these 
methods require a prior effort to establish an "account" or other evidence of credit 
worthiness. For a large number of consumers, e.g. all potential users of a large network of 
5 computers like the Internet, setting up accounts and maintaining credit information adds 
expense to the vendors, and inconvenience and impediments to the consumers. 

The recent growth of public access communications networks, such as the Internet, 
has accelerated the need for a low-cost computerized electronic commerce system. In 
addition, in the information marketplace there is a particular need to economically support 

10 transactions that are for amounts as small as a hundredth of a cent. 

U.S. Patent No. 5,802,497 (the '497 patent) describes a lightweight and secure 
protocol for electronic commerce over the Internet. The protocol is designed to support 
purchases costing less than a cent. The system is based on decentralized validation of 
electronic cash at a vendor's server, without any additional communication, expensive 

1 5 encryption, or off-line processing. 

Two innovations in the *497 patent are its use of brokers and scrip. Brokers take care 
of account management, billing, connection maintenance, and establishing accounts with 
vendors. Scrip is digital cash that is valid for only a specific vendor. The vendor locally 
validates the scrip to prevent customer fraud, such as double spending. 

20 Every time a user visits a new vendor, the user must get scrip for that vendor from a 

broker. Scrip is held and manipulated by the user using an application called a "wallet." The 
wallet includes scrip with each request to purchase content and gets back change from the 
vendor with the returned content. 

For each piece of scrip in the wallet, the wallet holds a secret (the "Customer Secret" 

25 or "CS"). The wallet uses the CS to prove to the vendor that the consumer is authorized to 
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spend the scrip. The wallet must protect the CS from third parties. Otherwise, an 
unauthorized third party with access to the wallet could spend the scrip. 

Accordingly, there is need to encrypt the scrip's CS stored by the wallet. The 
encryption should be relatively robust (i.e., difficult to decipher), but need not be excessive 
5 given the low value of the scrip. Moreover, the encryption should not add excessive ^ 
overhead to the electronic commerce system nor make the system harder to use by the 
consumer. 



Summary of the Invention 

1 0 The above needs are met by a method and system of conducting computerized 

commerce on a number of computer systems connected by a computer network. The system 
includes a broker computer system having a database of broker scrips, each broker scrip 
representing a form of electronic currency. The system also includes a vendor computer 
system having a database containing products which may be exchanged for the broker scrips, 

15 the vendor computer system capable of providing vendor scrips. In addition, the system 
includes a consumer computer system having a user interface whereby a consumer may 
initiate transactions in the consumer computer system to obtain one or more of the products 
contained in the database of the vendor computer system. 

Each piece of scrip has a value, which may range from a few dollars to a few 

20 hundredths of a cent. In addition, each piece of scrip has a Scrip ID which uniquely identifies 
the scrip and a Customer ED which identifies the consumer entitled to spend the scrip. The 
scrip also has a stamp that is used to verify that the scrip has not been altered. 

When issuing scrip, the broker generates a customer secret (CS) from the Customer 
ID and sends the CS and scrip to the consumer. If the CS is the first CS received by the 

25 consumer, the broker uses a secure channel to transmit the CS. Otherwise, the broker uses 
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the old CS to communicate the new CS to the consumer without actually transmitting the new 
CS in the clear. The consumer holds the scrip and its associated CS in a database called a 
"wallet." 

When the consumer desires to purchase product from the vendor, the consumer sends 
5 the vendor a request, the scrip, and a hash of the scrip, request, and CS. Preferably, the 
hashing algorithm is MD5, although other hashes can be used instead. The vendor verifies 
that the consumer has not tampered with the scrip and verifies that the consumer possesses 
the correct CS. If the consumer has transmitted valid scrip and proves knowledge of the 
correct CS, the vendor provides the requested product to the consumer. 

10 To keep third parties from accessing the wallet and spending the consumer's scrip, the 

customer secrets in the wallet are encrypted using a consumer-provided pass phrase. To 
strengthen the pass phrase, the wallet preferably concatenates the consumer-provided phrase 
with a first nonce (a random, guaranteed unique string) and a short random number, thereby 
forming an internal pass phrase. The length of the short random number, i.e. the number of 

1 5 bits in the number, is determined by the processing power of the consumer's computer 
system. The first nonce is stored in a header of the wallet file. 

The wallet hashes the internal pass phrase with a second nonce to generate a 
checksum. Then, the wallet stores a triple having the checksum, the second nonce, and the 
length of the short random number. In addition, the wallet encrypts the CS associated with 

20 each scrip by hashing a unique nonce with the internal pass phrase and then XORing the 

result with the CS. For each scrip, the wallet stores a triple holding the scrip, the nonce used 
to encrypt the CS, and the encrypted CS. Preferably, all of the nonces and the short random 
number are changed, and the checksum and hashes are regenerated, each time the wallet is 
written. 



4 



WO 00/57370 PCT/US00/07141 

To unlock the wallet and spend the scrip, the consumer provides a pass phrase. The 
wallet concatenates the provided pass phrase with the first nonce. In addition, the wallet 
appends a random number having the length read from the triple holding the checksum to the 
provided pass phrase/first nonce string. Then, the wallet calculates the hash of the second 
5 nonce and the provided pass phrase, the first nonce, and the random number, and determines 
whether the result matches the checksum. The hash is performed with all possible values for 
the random number until either a match is found or all possible values have been tried. If a 
match is found, the wallet treats the concatenation of the consumer's pass phrase, the nonce, 
and the random number as a single internal pass phrase. Then, the wallet decrypts the CS in 
10 the wallet by hashing the nonce for the scrip with the internal pass phrase and XORing the 
result with the encrypted CS. If no match is found, then the consumer, or some unauthorized 
party, has given an invalid pass phrase. Thus, the encrypted CS cannot be decrypted, and the 
scrip cannot be spent, without the proper consumer-provided pass phrase. 



1 5 Brief Description of the Drawings 

FIGURE 1 is a top-level block diagram of a computerized system for conducting 
computerized commerce; 

FIGURE 2 is a block diagram of a computer system used in the system of FIG. 

l; 

20 FIGURE 3 is a flow diagram of the operations of the system of FIG. 1 ; 

FIGURE 3 A is a flow chart of certain operations depicted in FIG. 3; 
FIGURE 3B is a flow chart of other operations depicted in FIG. 3; 
FIGURE 4 is a block diagram illustrating the data fields of a piece of scrip used in the 
system of FIG. 1; 



5 
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FIGURE 5 is a flowchart illustrating the steps performed by a preferred embodiment 
of the present invention to password protect the scrip in the wallet from a third party attack; 

FIGURE 6 is a block diagram illustrating the logical structure of a wallet file on a 
consumer computer system; and 

FIGURE 7 is a flowchart illustrating the steps performed by a preferred embodiment 
of the present invention when a consumer logs into the wallet. 

Detailed Description of the Preferred Embodiments 
FIG. 1 shows a computerized system 100 for conducting computerized commerce 
according to the principles of the invention. The system 100 includes a broker system 1 10, a 
vendor system 120, and a consumer system 130 interconnected by a communications network 
140. 

For clarity, the system 100 depicted in FIG. 1 shows only single broker, vendor, and 
consumer systems. In actual practice, any number of broker, vendor, and consumer systems 
can be interconnected by the network 140. 

The user 1 1 1 of the broker system 110 can be a bank, a credit provider, an Internet 
service provider, a telephone company, or any other institution the consumer trusts to sell 
scrip. The vendor system 120 is operated by a vendor 121. The vendor 121 provides 
products 150 of any type to consumers. 

A consumer 131 can use the consumer computer system 130 to "electronically" 
acquire the products 1 50 of the vendor 121 . The network 140 can be public or private, such 
as, for example, the Internet, a switched telephone system, a satellite linked network, or 
another form of network. 

A computer system 200 suitable for use as the broker, vendor, and consumer systems 
is shown in FIG. 2. The computer system 200 includes a central processing unit (CPU) 210, 
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a memory 220, and an input/output interface 230 connected to each other by a 
communications bus 240. The CPU 210, at the direction of users 250, e.g. brokers, vendors, 
and/or consumers, executes software programs for manipulating data. The programs and data 
can be stored in the memory 220 as a database (DB) 221 . The DB 221 storing programs and 
data on the consumer computer system 130 is referred to as a "wallet." 

The memory 220 can include volatile semiconductor memory as well as persistent 
storage media, such as disks. The I/O interface 230 is for communicating data with the 
network 140, the users 250, and other computer system peripheral equipment, such as 
printers, tapes, etc. 

The computer system 200 is scaled in size to function as the broker, vendor, or 
consumer systems. For example, when scaled as the consumer computer system 130, the 
computer system 200 can be a small personal computer (PC), fixed or portable. The 
configurations of the computer system 200 suitable for use by the broker 1 1 1 and the vendor 
121 may include multiple processors and large database equipped with "fail-safe" features. 
The fail-safe features ensure that the database 221 is securely maintained for long periods of 
time. 

FIG. 3 and FIG. 3 A show an operation of the system 100 according to a preferred 
embodiment of the invention. The consumer 131 in step 3015 uses currency to purchase 
electronic broker scrip 320 generated in step 301 0 by the broker 111. Here, purchasing 
means that upon a validation of the authenticity of the consumer 131 and the consumer's 
currency 310, the broker system 110 generates signals, in the form of data records. The 
signals in step 3020 are communicated, via the network 140, to the consumer system 130 for 
storage in the wallet 221 of the memory 220 of the consumer system 130. 

The currency 310 which is exchanged for scrip 320 can be cash, check, credit card, 
bank ATM card, debit card, phone card, or other items of value. The scrip 320 can also be 
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freely exchanged for "coupons" frequently used in promotional schemes. The "coupons" can 
be in form of the scrip. 

The scrip is described in further detail below. In brief, the scrip is stamped by the 
generator of the scrip. This means that the scrip carries information that is verifiable by only 
5 the originator. In addition, each scrip is uniquely identifiable. After a single use, the 
originator of the scrip can "invalidate it." Invalidated meaning that the signals of the data 
record are no longer accepted for processing by the originating computer system. 

Preferably, the broker system 1 10 in step 3027 executes licensed software programs 
which generate vendor scrip 330 for the consumer 131 as needed. In this case, the "value" of 
10 the license can be proportional to the amount of scrip that the licensee can generate. 

Alternatively, the broker 1 1 1 , in a similar transaction 303, as described above, exchanges 
currency 3 10 for bulk electronic vendor scrip 330 in step 3030 and 3035. The vendor scrip 
330 is generated in step 3025 by the vendor system 120. 

The consumer 131 desiring the products 150 provided by the vendor 121, can 
15 exchange 3040, 3045, 302 the broker scrip 320 for vendor scrip 330. If the purchase price of 
the product 150 is less than the value of the vendor scrip 330, new vendor scrip can be issued 
for the balance as "change." A separate transaction type allows consumers 131 to ask vendors 
121 to turn vendor scrip 330 back into currency 310 or broker scrip 320, probably for a fee. 

In an alternative embodiment shown in FIG. 3, FIG. 3A and FIG. 3B, the consumer 
20 131 can establish an "account" with the vendor 121 to acquire vendor scrip 330 directly, 

without the need of a third party broker as indicated in steps 3055 and 3060. Establishing an 
account means that an account data record is maintained in the vendor computer system 120. 

The consumer 131, in a transaction 304, submits in step 3045, the vendor scrip 330 to 
the vendor 121. The vendor 121 decrypts the vendor scrip 330 to verify its authenticity, and 
25 to validate the "currency" amount. Verification also checks the local database to determine 
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whether the scrip is previously unspent. Approval of the transaction 303 results in the 
delivery of the desired product 150 to the consumer 131 in step 3050. In the transaction 304, 
change can also be returned to the consumer 1 3 1 in the form of vendor scrip having a value 
which is the amount of the over-payment, e.g., another data record communicated by the 
5 network 140. 

The electronic signals which represent the scrip, and which are processed and 
communicated by the system 100 are described with reference to FIG. 4. FIG. 4 is a block 
diagram illustrating the data fields of a single piece of scrip 400 according to one 
embodiment of the present invention. The scrip 400 is logically separated into seven data 

10 fields. The Vendor field 410 identifies the vendor for the scrip 400. The Value field 412 
gives the value of the scrip 400. The Scrip ID field 414 is the unique identifier of the scrip. 
The Customer ID field 416 is used by the broker 1 1 1 and vendor 121 to determine a customer 
secret ("CS") for the scrip. The Expires field 418 gives the expiration time for the scrip 400. 
The Props field 420 holds customer properties, such as the customer age, state of residence, 

1 5 etc. Finally, the Stamp field 422 holds a digital signature and is used to detect tampering of 
the scrip 400. 

When issuing scrip, the broker 1 1 1 generates the CS based on the Customer ID and 
transmits it to the consumer 131. If this is the first piece of scrip purchased by the consumer 
131 from the broker 1 1 1, the CS is provided to the consumer 13 1 via a secure channel. 

20 If the consumer 131 has already received a CS from the broker 111, then the broker 

1 1 1 (or vendor 121, if the vendor is giving change or a refund) uses the previously provided 
CS (the old CS, or OCS) to transmit a new CS (NCS) to the consumer 131 without requiring 
a secure channel. The broker 1 1 1 calculates the NCS by using the Customer ID field 416 in 
the same manner that the OCS was calculated. Then, the broker 1 1 1 calculates a result as 

25 follows: 
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result = NCS XOR H(cs_nonce, OCS), 
where H() is a hash function, "XOR" is the exclusive-or function, and cs_nonce is a nonce, 
i.e., a random, guaranteed unique string. In one embodiment, the hash function used 
throughout the electronic commerce system is MD5, described in R. Rivest, "The MD5 
5 Message Digest Algorithm," RFC 1321, April 1992, which is hereby incorporated by 
reference herein. The result and the cs_nonce are passed to the consumer 131. 

When the consumer 131 receives the result and cs_nonce, the consumer 131 derives 
the NCS by performing the calculation: 

NCS = result XOR H(cs_nonce, OCS). 
10 The consumer 13 1 preferably stores the NCS with the corresponding scrip 400 in the wallet 
221. Thus, the broker 1 1 1 communicates the value of the NCS to the consumer 131 without 
actually transmitting the NCS. The consumer 131 uses the CS to prove ownership of, i.e. 
possession of the right to spend, scrip. 

In a preferred embodiment of the present invention, the consumer 131 requests 
15 product from the vendor 121 in the context of the World Wide Web (WWW). Accordingly, 
the request is phrased as a uniform resource locator (URL) pointing to a location at a vendor- 
controlled domain. 

To spend scrip 400 for a product, the consumer 131 sends the vendor 121 a message 
in the form: 

20 scrip, request, H(scrip, request, CS), 

where scrip is the vendor scrip 400 issued to the consumer, the request is the URL specifying 
the requested product, and H(scrip, request, CS) is a hash of the scrip, request, and the CS. 
Thus, the consumer 131 sends the scrip in the clear (unencrypted). 

When the vendor 121 receives the scrip 400, the vendor 121 first validates the Stamp 

25 field 422 to ensure that the scrip 400 was not altered. Next, the vendor 121 uses the CS to 
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validate that the consumer 131 is authorized to spend the scrip 400. Once the vendor 121 has 
validated the scrip 400 and consumer 131, the vendor preferably provides the requested 
product to the consumer 131. Also, the vendor 121 may issue scrip to the consumer 131 as 
change by using the techniques described above. 
5 Implicit in the above description of the electronic commerce system is that the 

consumer 131 must keep confidential the CS of the scrip 400 in the wallet 221. Otherwise, 
an unauthorized third party could spend the scrip 400 without the knowledge of the consumer 
131. Accordingly, the CS in the wallet 221 must be protected from attack. Therefore, a 
preferred embodiment of the present invention uses a strengthened password scheme to 

1 0 encrypt the CS in the wallet 22 1 . 

FIG. 5 is a flowchart illustrating the steps performed by a preferred embodiment of 
the present invention to protect the scrip 400 in the wallet 221 from a third party attack. In 
addition, FIG. 6 is a block diagram illustrating the logical structure of the wallet file 221 in 
the consumer computer system 130. First, the consumer 131 provides 510 a pass phrase for 

15 the wallet 22 1 . To provide the best security, the pass phrase should be long, contain upper 
case and lower case letters, contain numbers, contain punctuation marks, and not be a word. 
However, consumers 130 typically choose poor (i.e., easily guessable) pass phrases. 

Therefore, the wallet 221 uses the consumer-chosen pass phrase as a portion of an 
internal pass phrase. To form the internal pass phrase, the wallet 221 preferably appends 512 

20 a nonce, called the pp_nonce, to the end of the consumer-chosen pass phrase. In addition, the 
wallet 221 generates 514 an n-bit random number (i.e., a random string of bits) and appends 
the random number to the consumer-chosen pass phrase/pp_nonce string. The resulting 
string is the internal pass phrase. The pp_nonce is written to a header 610 in the wallet 221. 
The length of the n-bit random number is preferably determined by the capabilities of 

25 the consumer's computer system 130. For example, in one embodiment the length of the 
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random number is determined by the time it takes the consumer's computer system 130 to 
perform the basic unit of an encryption algorithm (in a preferred case, MD5). This 
embodiment determines how many calculations the computer system 130 can perform in 
some time duration, such as one second, and then picks the length of the number so that the 
5 calculations to guess the number take "long enough," For example, if the computer system 
130 can perform 500,000 calculations in a second, the random number could be about 20 bits 
in length. Since 20 bits corresponds to about one million values, on the average it would take 
500,000 calculations for the consumer's computer system 130 to guess the correct value of 
the random number, adding an average delay of one second to the time required to validate 

10 the consumer's pass phrase. 

A checksum is generated 516 from the internal pass phrase by the equation: 
checksum = H(checksum_nonce, internal pass phrase), 
where the checksum_nonce is a new nonce. The triple (checksum_nonce, length, checksum) 
612 is then stored 518 in the wallet 221, where "length" is the number of bits in the random 

15 number. 

In addition, each CS associated with a scrip 400 held in the wallet 221 is also 
encrypted 520 using the internal pass phrase. Preferably, an encrypted CS (ECS) is formed 
using the equation: 

ECS = H(ecs_nonce, internal pass phrase) XOR CS, 
20 where the ecs_nonce is a different nonce than the nonces described above. This manner of 
encryption is effective because the hash result has the same number of bits as the CS and the 
exclusive-or function can be used to encode the ECS. For each scrip, the wallet stores a 
(scrip, ecs_nonce, ECS) triple 614 with a unique nonce. Accordingly, the scrip secrets are 
encrypted and the scrip 400 is unusable without the internal pass phrase. Preferably, new 



12 
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nonces are generated every time the wallet file is written, thereby causing a new internal pass 

phrase, a new checksum, and new ECS to be written to the wallet 221 . 

FIG. 7 is a flowchart illustrating the steps performed by a preferred embodiment of 

the present invention when a consumer 1 3 1 logs into the wallet 22 1 . First, the consumer 1 3 1 

5 provides a pass phrase to the wallet 221 . In response, the wallet 221 reads the pp_nonce from 

the header 610 of the wallet and reads the (checksum_nonce, length, checksum) triple 612 

stored in the wallet. Next, the wallet 221 begins calculating the hash function for all possible 

values of the n-bit random number having the length described in the triple 612: 

H(checksum_nonce, provided pass phrase + pp nonce + 00000. . .000) 
10 H(checksum_nonce, provided pass phrase + pp_nonce + 00000. . .001) 

H(checksum_nonce, provided pass phrase + pp_nonce + 00000. . .010) 
H(checksum_nonce, provided pass phrase + pp_nonce + 00000. . .01 1): 
. . 

15 where "provided pass phrase" is the phrase provided by the consumer 13 1 and the 
operator denotes concatenation. 

As each hash is generated, the wallet 221 tests 712 the value of the hash against the 
checksum stored in the triple 612. If the hash matches 714 the checksum, then the consumer 
13 1 has provided a valid pass phrase. If none of the hashes match the checksum, the 

20 provided pass phrase is invalid and the wallet 22 1 denies access to the consumer 131. 

In a preferred embodiment of the present invention, the search for the short random 
number does not always start with the same initial value. If it did, an attacker could time how 
long the wallet 221 took to find the correct number and then use that time to narrow the range 
of possible values. Accordingly, the search preferably starts at a random value in the correct 

25 range and then wraps around to the initial value if a match is not found in the upper part of 
the range. 

Once a matching pass phrase is found, the wallet 221 preferably decrypts the ECS for 
the scrip 400 in the wallet. For each scrip, the wallet 221 reads the (scrip, ecs_nonce, ECS) 
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triple 614 and repeats the calculation used to derive it, except that instead of XORing the 
H(ecs_nonce, internal pass phrase) calculation with the CS, the wallet XORs it with the ECS. 
Thus, the wallet 221 performs the calculation: 

CS = H(ecs_nonce, internal pass phrase) XOR ECS 
5 to decrypt each CS. 

The described invention for strengthening the pass phrases protects the wallet 221 
from consumers' 130 poor choices of pass phrases. The nonce makes all internal pass 
phrases unique, even if the consumers choose common pass phrases. Thus, the explicit nonce 
helps protect the wallet 221 from an off-line, pre-computed attack. 

10 Most importantly, the random number raises the effort required by a "dictionary" 

attack. A dictionary attack is possible because consumers 130 choose bad pass phrases - 
often ordinary words. An attacker could take a large dictionary and just try every word in the 
dictionary as the consumer's pass phrase. If the consumer 131 chooses a word in the 
dictionary, then eventually the attacker will find the pass phrase. 

1 5 Since computers are getting faster, the cost of a dictionary attack is decreasing. 

However, adding the random number to the pass phrase raises the cost of checking each 
dictionary entry. Instead of doing just one hash to test each word, the attacker must perform 
many hashes — one for each possible value of the random number — for each entry. As 
computers get faster, the length of the random string is increased to keep the cost of a 

20 dictionary attack relatively constant. 

In addition, the disclosed invention limits the total volume of the material that is 
encrypted. Since only the CS of each piece of scrip is encrypted rather than the entire body 
of the scrip, the present invention may be utilized in environments where bulk encryption 
systems and methods are prohibited or undesirable. 
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1 8. A method of decrypting encrypted data, comprising the steps of: 

2 accepting a pass phrase; 

3 hashing the pass phrase with a first nonce to produce a first result; and 

4 decrypting the encrypted data with the first result. 

1 9. The method of claim 8, wherein the decrypting step comprises the step of: 

2 exclusive-oring the first result with the encrypted data. 

1 10. The method of claim 8, further comprising the steps of: 

2 concatenating the pass phrase, a second nonce, and a random number to form a 

3 concatenated pass phrase; 

4 hashing the concatenated pass phrase with a third nonce to produce a second 

5 result; and 

6 comparing the second result to a previously calculated checksum; 

7 wherein the decrypting step occurs if the second result matches the checksum. 

1 11. The method of claim 1 0, further comprising the step of: 

2 iterating the concatenating, hashing, and comparing steps using different numbers 

3 of a same length until a stopping condition is reached; 

4 wherein the stopping condition is reached when the second result matches the 

5 checksum; and 

6 wherein the stopping condition is reached when all of the numbers having the 

7 same length have been compared without the second result matching the 

8 checksum. 

1 12. The method of claim 1 1 , further comprising the step of: 

2 selecting a first number having the same length; 

3 wherein the iterating step starts at the selected first number, increments the 

4 number for each iteration, and wraps around to the lowest possible number 

5 having the same length if the highest possible number having the same 

6 length is reached without reaching a stopping condition. 
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1 1 3. A computer program product having a computer readable medium, the 

2 computer readable medium having computer instructions encoded thereon for encrypting 

3 data, the computer instructions comprising instructions for: 

4 accepting a pass phrase; 

5 hashing the pass phrase with a first nonce to produce a first result; and 

6 encoding the first result with the data to produce encrypted data. 

1 14. The computer program product of claim 13, wherein the instructions for 

2 encoding comprise instructions for: 

3 exclusive-oring the first result with the data. 

1 15. The computer program product of claim 1 3 , further comprising instructions 

2 for: 

3 concatenating the pass phrase, a second nonce, and a random number to form an 

4 internal pass phrase; 

5 wherein the hashing instructions utilize the internal pass phrase. 

1 16. The computer program product of claim 13, further comprising instructions 

2 for: 

3 hashing the pass phrase with a third nonce to produce a first checksum. 

1 17. The computer program product of claim 1 6, further comprising instructions 

2 for: 

3 comparing a second checksum with the first checksum; and 

4 decrypting the encrypted data if the second checksum matches the first checksum. 

1 18. The computer program product of claim 1 7, wherein the instructions for 

2 decrypting the data comprise instructions for: 

3 hashing the pass phrase with the first nonce to produce a second result; and 

4 decoding the second result with the encrypted data to produce the decrypted data. 
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1 1 9. The computer program product of claim 1 8, wherein the instructions for 

2 decoding comprise instructions for: 

3 exclusive-oring the second result with the encrypted data. 

1 20. A computer system, comprising: 

2 a memory for holding data; 

3 a module for receiving a pass phrase for the data held in the memory; 

4 a module for hashing a first nonce with the pass phrase to produce a first result; 

5 and 

6 a module for encoding the first result with the data to produce encrypted data. 

1 21. The computer system of claim 20, wherein the module for encoding 

2 comprises: 

3 a module for exclusive-oring the result with the data. 

1 22. The computer system of claim 20, further comprising: 

2 a module for combining the pass phrase with a second nonce and a random 

3 number to form an internal pass phrase; 

4 wherein the module for hashing utilizes the internal pass phrase. 

1 23 . The computer system of claim 22, further comprising: 

2 a module for hashing the internal pass phrase with a third nonce to produce a first 

3 checksum. 

1 24. The computer system of claim 23, further comprising: 

2 a module for comparing a second checksum with the first checksum; and 

3 a module for decrypting the encrypted data if the second checksum matches the 

4 first checksum. 

1 25. The computer system of claim 24, wherein the module for decrypting the data 

2 comprises: 

3 a module for hashing the internal pass phrase with the third nonce to produce a 

4 second result; and 
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Claims 

We claim: 

1 1 . A method of encrypting data, comprising the steps of: 

2 accepting a pass phrase; 

3 hashing a first nonce with the pass phrase to produce a result; and 

4 encoding the result with the data to produce encrypted data. 

1 2. The method of claim 1 , wherein the encoding step comprises the step of: 

2 exclusive-oring the result with the data. 

1 3. The method of claim 1 , further comprising the step of: 

2 strengthening the pass phrase to make the pass phrase harder to determine; 

3 wherein the hashing step uses the strengthened pass phrase. 

1 4. The method of claim 3, wherein the strengthening step comprises the step of: 

2 concatenating the pass phrase, a second nonce, and a random number to form the 

3 strengthened pass phrase. 

1 5. The method of claim 4, wherein the method steps are performed on a 

2 computer system and further comprising the step of: 

3 determining a length of the random number from a processing speed of the 

4 computer system. 

1 6. The method of claim 4, further comprising the step of: 

2 storing the first nonce, the second nonce, and a length of the random number with 

3 the encrypted data. 

1 7. The method of claim 1 , further comprising the step of: 

2 hashing the pass phrase with a third nonce to produce a checksum; 

3 wherein the encrypted data cannot be decrypted without reproducing the 

4 checksum. 
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Having described a preferred embodiment of the invention, it will now become 
apparent to those skilled in the art that other embodiments incorporating its concepts may be 
provided. It is felt therefore, that this invention should not be limited to the disclosed 
invention, but should be limited only by the spirit and scope of the appended claims. 
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5 a module for decoding the second result with the encrypted data to produce the 

6 decrypted data. 

1 26. The computer system of claim 25, wherein the module for decoding the 

2 second result comprises: 

3 a module for exclusive-oring the second result with the decrypted data. 
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